微服務（Microservices）架構已經是現代軟體開發的熱門選擇。許多人一談到微服務，往往直接聯想到 Kubernetes，彷彿兩者劃上了等號。事實上，微服務是一種 軟體架構模式，而 Kubernetes 則是一種部署與管理容器的平臺。兩者雖然契合，但並非必然關係。

在這篇文章，我們將探討微服務的部署議題，包括 Container、VM、Sidecar、Service Mesh 等關鍵技術，釐清它們的定義、適用情境與技術細節，幫助大家更清楚地規劃微服務系統的部署策略。

微服務的部署挑戰

在單體應用程式（Monolith）時代，整個應用部署在單一伺服器或 VM 上，運維相對單純。但隨著系統演進成微服務後，會遇到以下部署挑戰：

1. 服務數量暴增：一個應用可能拆分成數十個甚至上百個微服務。
2. 異質環境：不同服務可能使用不同語言、框架或依賴環境。
3. 資源利用率：如何讓服務共享硬體資源而不互相干擾？
4. 網路通訊與治理：服務之間需要安全、可靠、可觀測的通訊機制。
5. 版本與升級：如何支援藍綠部署、金絲雀釋出，避免停機？

為了因應這些挑戰，部署技術從傳統 VM，到 Container，再到 Service Mesh，一路演進。

虛擬機（VM, Virtual Machine）

VM 是在一台實體伺服器上，透過 Hypervisor（如 VMware ESXi、KVM、Hyper-V）模擬多台「虛擬伺服器」，每台 VM 都擁有自己的 OS、資源隔離與應用執行環境。

適用情境

• 傳統應用程式：適合尚未容器化的舊系統。
• 高隔離需求：每個 VM 擁有獨立的 OS 層級，安全性較高。
• 混合部署：某些應用需要特定 OS 版本或驅動程式，只能在 VM 中執行。

技術評估

• 每個 VM 都需要安裝完整的 OS → 資源開銷大。
• 啟動時間慢（幾十秒至數分鐘）。
• 可搭配自動化工具（如 Ansible、Terraform）來管理 VM 部署。

容器 (Container)

容器是一種輕量級的虛擬化方式，透過共享主機 OS Kernel，實現應用與環境的封裝與隔離。代表技術如 Docker、Podman。

適用情境

• 微服務架構的最佳拍檔：快速啟動、易於遷移，適合頻繁部署。
• 雲原生應用：支援 CI/CD、自動伸縮、彈性運算。
• 跨平台一致性：開發環境與生產環境保持一致。

技術實作

• 容器映像檔（Image）包含應用程式與依賴，啟動時間可縮短至秒級。
• 搭配容器編排（Kubernetes、OpenShift、Rancher），可達到高可用、彈性伸縮。
• 容器之間使用網路隔離，透過 Service 或 API Gateway 互通。

Sidecar 模式

Sidecar 是一種部署模式，指在同一個 Pod（或 VM）內，主應用服務（Main Service） 與 輔助服務（Sidecar Service） 一起執行，Sidecar 專責處理與主服務相關但非核心的功能。

常見例子：
• Proxy：處理流量控制、加密、重試、負載平衡。
• Logging Agent：收集主服務的日誌並傳送到集中式儲存。
• 監控代理（Metrics Collector）：收集服務效能數據。

技術實作

• 常見實作：Envoy Proxy、Fluent Bit、Prometheus Agent。
• Sidecar 模式最讓人詬病的就是每個服務多了一個 Sidecar，耗費了運算資源。

服務網格 (Service Mesh)

Service Mesh 是一種「專門用來管理微服務通訊」的基礎設施層。它將服務間的網路通訊、流量控制、安全治理，抽離到基礎設施中，通常採 Sidecar Proxy 架構（例如 Istio、Linkerd、Consul Connect）。

適用情境

• 大規模微服務系統：上百個服務互動，需要統一治理。
• 零信任安全模型：透過 mTLS 驗證、加密。
• 流量管理：支援藍綠部署、金絲雀釋出、流量分割。
• 可觀測性：提供 Trace、Metrics、Logging 三大可觀測性支柱。

技術實作

• 資料平面（Data Plane）：由 Sidecar Proxy（如 Envoy）組成，處理實際流量。
• 控制平面（Control Plane）：統一配置與策略下發（如 Istio Pilot、Linkerd Control Plane）。
• 成本：需要額外的資源與學習曲線。

部署模式比較

模式|定義｜適用情境|優點|缺點
-----| -----| -----| -----| -----|
VM|硬體虛擬化，模擬完整 OS|傳統應用、高隔離需求|高度隔離、安全|資源開銷大、啟動慢
Container|輕量級虛擬化，共享 Kernel|微服務、雲原生應用|輕量、快速、可移植|隔離性低於 VM
Sidecar 主服務旁的輔助服務 日誌、監控、流量代理 功能解耦、語言無關 資源開銷高、複雜度增加
Service Mesh 管理服務間通訊的基礎設施 大規模微服務、零信任 強大流量控制、安全治理 成本高、學習曲線陡峭

結語

微服務的部署不是單一解答，而是一個演進過程：

1. 最初從 VM 開始，逐步走向 Container。
2. 為了支援額外功能，引入 Sidecar。
3. 當系統規模達到一定程度，自然會需要 Service Mesh 來統一治理。

因此，我們不應將「微服務」與「Kubernetes」混為一談，而應該理解：
• 微服務是一種架構理念。
• Kubernetes 與 Service Mesh 則是實現微服務的強大工具。

部署策略的選擇，應依據系統規模、業務需求、團隊能力來決定。最重要的不是盲目跟隨潮流，而是讓技術真正解決業務問題。